home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
SPACE 1
/
SPACE - Library 1 - Volume 1.iso
/
program
/
113
/
gfatip05
/
gfatip05.txt
< prev
next >
Wrap
Text File
|
1987-11-28
|
6KB
|
122 lines
June 14,1987
GFATIP05.DOC
by John B. Holder
Senior Software Engineer
Marathon Computer Press
Asst. Sysop on GEnie's MichTron Roundtable
USING THE EXEC COMMAND IN GFA BASIC
This is the fifth in a planned series by this author on
getting the most out of your GFA Basic Investment. In this Tip
file we will briefly cover the EXEC command and some of it's
possibilities and peculiarities.
There are several possibilities with this command, however I
will brush on just a few. With the EXEC command you can either
load and execute or load and wait for a subsequent execution time.
Since the upcoming book by GFA Systemtechnik will go into detail
of how to load a program and execute it on call, I will skip over
that option. The immediate load and go is the most common usage
of the EXEC command so that will be the mode discussed in this doc
file and in the GFATIP05.BAS and GFATIP51.BAS files.
1. To simply load a program and execute it from a running
application we would do something like this:
Reserve Fre(0)-Spaceneeded
Exec 0,"Your.Prg","",""
Now you may ask how much is needed? Well, you must reserve
enough for the entire program you are loading to fit into a block
of memory & you must also allow enough room for it's stack and
data storage area as well. This is a process of dynamic memory
allocation for your called program. So now you might ask, what is
the point that I start at? How much do I give it? Well, once
again you have to experiment a bit here to find just the right
amount. Start out a little higher than you think you need first,
and then run your basic program and work the reserved memory down
until you have the minimum required to execute it successfully.
If you have not allocated enough memory the load and go will fail,
and the program will not run. In that case, just allocate more
memory and try a run again.
Now once you have successfully accomplished the allocation of
memory and the execution of your called program, YOU MUST return
the memory to the memory pool by doing this:
Reserve Fre(0)+Spaceneeded-255
If you do not return the memory, it will be retained by the
system and will continue to reduce itself if the program is called
repeatedly. Not only that, the parent program will not have the
memory resource following the return of control without the
restoration function mentioned above. The GFATIP05.BAS and
GFATIP51.BAS files will show you how this MUST be done.
2. Other Possibilities:
If you would like to call a TTP program and pass in a command
to it you must use the following calling convention:
Suppose the command is
ah new.arc *.bas
(For ARC.TTP)
Command$="ah new.arc *.bas"
Command_length=Len(Command$)
Command$=Chr$(Command_length)+Command$+Chr$(0)
Reserve Fre(0)-Spaceneeded
Exec 0,"Your.Prg",Command$,""
Reserve Fre(0)+Spaceneeded-255
That's all there is to it. Essentially, what we did was
formulate a command in our mind (it must be a legal one for the
program you are passing it to), place the command into a string
variable, find out the length of the string, reconstruct the
command as this:
Length of the command, Actual Command, A null Byte for Padding
Other than that, the format is the same as that which the
other flavor of EXEC command uses.
3. Peculiarities:
If you are calling a compiled GFA Basic program from a parent
interpreted Basic program, many times following the return from
the child (compiled basic program you called), you will be
presented with an alert box asking if you would like to continue
or quit. This is because the compiled GFA Basic program is
passing the interpreted program a signal that says "Let's end".
It is sort of like pressing the Control+Shift+Alternate keys.
This peculiarity goes away if you compile the program. In other
words, if all of your programs are compiled (Parent, and Child),
then you will not have this problem. This is not a problem if you
don't mind having your program interrupted during development.
Now you see why I have included a Demo Program written in
Modula 2 for an example. This way those of you using Interpreters
only can run the GFATIP05.BAS file without interruption. Since
Modula 2 uses a different exiting sequence, this "Break" does not
arise.
To see the Break example run GFATIP51.BAS. You will see the
difference as ICON.PRG is a compiled GFA Basic program. The Icon
Demo came from the GFA Basic Companion's Source Code Libraries.
The GFA Basic Companion will be available at a Software Dealer
near you or directly from MichTron soon.
I hope this helps many of you out. If you are interested in
getting some questions answered on a live basis, why not stop in
for one of our weekly GFA Basic Conferences on GEnie at 10:00PM
EST, 7:00PM PST every Saturday. A lot of GFA Experts and
Enthusiasts stop by each week. We'll be looking for you.